The system basic input/output system (BIOS) is designed to provide the essential interfacing between hardware and the operating system. In addition, Peripheral Component Interconnect (PCI) Option ROM provides some basic functionality such as PCI device initialization and the provision of INT 13 interface during a boot. PCI is a high-performance, 32-bit or 64-bit bus designed to be used with devices that have high bandwidth requirements, such as display subsystems. Small Computer System Interface (SCSI) is an I/O bus designed as a method for connecting several classes of peripherals to a host system without requiring modifications to generic hardware and software. PCI system interface defines a mechanism that is used to load a PCI option ROM (i.e. BIOS for a PCI device) from a conforming PCI device. The PCI option ROM is stored in a flash memory of the PCI device. Sometimes, the PCI option ROM is stored in the motherboard ROM, a system flash or the like. In most cases, the size of the PCI option ROM is limited to 64K to preserve the option ROM space available in the platforms. Conventionally, the option ROM provides some basic functionality such as device initialization and the provision of INT 13 interface. The PCI option ROM may also provide a configuration utility (CU) including additional functionality such as setting device configuration parameters and diagnostic tests for the PCI device. Many SCSI and Fibre Channel controllers include CUs bundled with the PCI option ROMs. Such CUs may present several problems such as:
1) debugging of the CU is limited to symbolic debugging or extracting debug information through a serial port for the CU. It may become extra overhead on developer resources.
2) any changes to the CU may require a complete build of the PCI option ROM. To test the changes, the new PCI option ROM should be stored and the machine rebooted.
3) the image size of the PCI option ROM includes the code and data space taken by the CU as well. Since the image size is typically limited to 64K, the amount of features that can be added is limited. In order to add new features, some other features had to be taken out. For example, in order to add RAID support, help text describing each selectable field has to be disabled for certain SCSI controllers. Thus, a significant amount of developing time is wasted counting bytes to fit the image size to 64K. Due to the image size limitation, feature addition or refinement to legacy product is near impossible.
4) additional separate modules cannot be introduced since all modules are bundled in a single package.
5) any changes to the PCI option ROM requires a test cycle for the CU and any change to the CU requires a test cycle for the PCI option ROM.
There are various approaches to resolve the above-described problems. Conventionally, a symbolic level debugger has been available to debug the CU in legacy products. However, the level of support provided by a symbolic debugger is very limited compared to a source level debugger. For example, the symbolic debugger does not provide high level of support in terms of line numbers, structure expansion, stack traces, variable look ups or the like. Therefore, debugging a given problem through a symbolic debugger is not as efficient as debugging through a source level debugger. Alternatively, an ICE (In-Circuit Emulator) debugger such as ECM-20 using JTAG port has been used to debug the configuration utility. However, this method requires expensive hardware to set up an ICE debugger or requires a CPU tap. For example, a JTAG chain requires a special port on the system motherboard. Further, setting up the JTAG chain requires some degree of manual intervention which is time consuming. A serial port has also been utilized to debug the configuration utility. However, this method is limited to extracting debug information printed out by the configuration utility. Further, breakpoints cannot be used and no stack traces can be printed. It is impossible to look into random locations in memory through this method.
Conventionally, in a legacy product development, whenever a change is made to the configuration utility, a new PCI option ROM incorporating the change has to be built and stored into a controller before the change can be tested. This approach is also time-consuming. However, there has been no method or system to prevent storing the new PCI option ROM to test changes to the CU in legacy products. It is necessary to store and reboot the target machine to test any changes to the CU.
In order to resolve the limitations of the image size of the PCI option ROM, a method for supporting multi-segment PCI option ROMs has been developed. However, such a method is vendor specific and not common. There is no method or system for introducing additional separate modules to the PCI option ROM. Conventionally, multiple independent functional modules are not supported in legacy BIOS products. Only the CU has been bundled with the PCI option ROM.
Therefore, it would be desirable to provide a method to reduce the burden on the PCI option ROM to piggyback the configuration utility and other applications. It would be also desirable to provide a method to test any changes to the applications without testing the PCI option ROM. It would be also desirable to provide a method to support additional functional modules to be executed during boot time.